I grit my teeth when I read that software engineering is not engineering because we don't suffer from any constraints. This Is Wrong, and off the top of my head, here are some reasons why:
- Where a builder uses wood, metal, sheetrock, etc. as their basic materials, we software engineers use algorithms both formally and informally specified. At its simplest, an algorithm is the set of instructions you give to the computer to accomplish some task. Basic algorithms (Quicksort, hash tables, and so on) are the software engineer's basic materials. Although it appears not to have been often thought of this way, each program/module/etc. is the implementation of an algorithm for solving that task, so we deal with large, complex (and often not well specified) algorithms all the time. I think of Quicksort et.al. as the wood, metal, etc., while larger algorithms (HTTP server, etc.) serve as the sills, soffits, bay windows, and so on.
- We do not live in a world of 0 cycle times and infinite memory (or disk). Each algorithm has different time/space requirements. A Perl array or linked list may be quite suitable for searching small lists of items, while a hash will likely be good for medium-sized lists, with (in Perl) a hash backed by a database might be needed for searching all medical entries in the U.S. Yellow Pages. Builders don't use 2x4s as the main structural elements in skyscrapers, nor do we software engineers use an in-memory hash to store all 3m-resolution images of the U.S.
- As software engineers, we struggle with the complexity of our designs all the time. It still amazes me how many general-purpose editors do not support regex search&replace with grouping (s/Jim said/$1 said/), more than 20 years since that feature first appeared (IIRC). Regexes, closures, rule-based systems, et.al. hide complexity so that (for the most part) we can concentrate on the design rather than implementation details. For example, languages such as Perl with integrated regexes make it easy to use regexes to solve otherwise complicated problems (as someone whose first 2 languages were FORTRAN IV and assembly, I cannot tell you how glad I am for Perl regexes and their kin). I have personally written 3 hash implementations to help me overcome implementation complexity (the last recently as the late 90's for a 15-year-old C system). Progress towards higher-level code constructs has made the jobs of all of us software engineers easier (come on, who these days would like to create something like Amazon in FORTRAN IV or circa-1980 Pascal? and without today's libraries and frameworks)
- In any system, the most complex subsystems are the ones with people embedded in them. Writing an OS kernel or a natural language subset interpreter is child's play compared to the complexities of dealing with multiple customers for the same product with conflicting requirements – and this does not cover the common case, where people know that they would like a computer system to help them solve their problem, but they cannot specify to you or how the computer system should accomplish that goal (they know the problem domain, but not the solution domain (and they may not even have had time to reason about their problem domain)).
It's not so much about Software Engineering...
Alias on 2007-08-11T20:14:41
My main disagreement is not with Software Engineering not being Engineering, it's just that most PEOPLE that call themselves Software Engineers are not Engineers (not registered with accredited body, meeting all the relevant criteria).
Re:It's not so much about Software Engineering...
jdavidb on 2007-08-16T15:15:52
I think anybody ought to have the right to call themselves whatever they want to call themselves, and there ought to be any number of potential accrediting bodies, and the market can decide which accrediting bodies matter, and how much.
Define family how you want it, define schooling how you want it, define engineering how you want it. Don't tell other people what they can and can't call themselves.
Re:It's not so much about Software Engineering...
From what I've seen, most engineers are not Engineers (i.e. registered with some accreditation body). I looked into this a couple of years when I was consulting full-time, only to find that I could not even become a Professional Software Engineer in Indiana, U.S.A., as Indiana did not even have a Professional Software Engineer registration process. For me, the ability to distinguish between a Professional Engineer and a regular engineer has been enough (and rarely a distinction with a difference -- many engineers could be Professional Engineers if they wanted to take the time).
